Skip to main content
Version: 5.3.0.0

Automatic Configuration

When Orchestra runs in container, cloud, or standalone environments, the methods for configuring the runtime and scenarios may vary. All configuration values can be injected from outside using operating system variables, allowing the software to adapt to different environments.

Orchestra can be configured to fit appropriately into container, cloud, and standalone environments: all configuration properties of the Orchestra runtime, scenarios, and components can be injected through system variables.

Since the configuration of Orchestra depends on the deployed scenarios and components, a fixed set of properties cannot be used. Consequently, the following sections describe the basic injection principles, which must be adapted to the specific deployment.

Activation of the Container Mode (Container Environment)​

The container mode is activated in the environment_settings.xml configuration file. The following sample demonstrates the configuration setting.

<!--
| ##########################################################################################
| # Runtime Settings
| ##########################################################################################
|
| containerMode defines if Orchestra operates in container mode.
| If set to true, the container mode is active.
| If set to false, the container mode is inactive.
-->
<group name = "runtime">
<parameter name = "containerMode" value = "{System.ORCHESTRA_CONTAINER_MODE_ACTIVE}" />
</group>

This configuration allows you to activate the container mode by setting the environment variable ORCHESTRA_CONTAINER_MODE_ACTIVE to true.

Only if the container mode is activated, all subsequent parameters in the configuration may be overwritten from outside in the container environment.

Injection of Orchestra Base Settings​

The names of the environment variables follow the pattern:

orchestra_settings_<group>_<parameter>

Note: If the group or parameter contains a dot or another special character, it will be replaced by an underscore.

Assuming you wish to override the parameters from the database group:

<group name = "database" enabled="true">
<parameter name="runtime.db.typ" value="${orchestra.db.runtime.typ}" />
<parameter name="runtime.url" value="${orchestra.db.runtime.url}" />
<parameter name="runtime.user" value="${orchestra.db.runtime.user}" />
<parameter name="runtime.pwd" value="${orchestra.db.runtime.pwd}" />
</group>

If the above parameters need to be injected, you must use the following names:

  • orchestra_settings_database_runtime_db_typ
  • orchestra_settings_database_runtime_url
  • orchestra_settings_database_runtime_user
  • orchestra_settings_database_runtime_pwd

Injection of Extended Settings via the Orchestra Monitor​

The same principle applies to settings that can be adjusted using the Orchestra monitor - settings panel. To obtain the correct names, please export the current settings as an XML file. In this file, you can see the exact spelling of the parameters, which consist of group and parameter names. The following example shows the export of the audit settings.

<group name="AuditService">
<setting name="monitor.base64" value="true"/>
<setting name="monitor.enabled" value="false"/>
<setting name="monitor.path" value="$/auditlog"/>
<setting name="monitor.reason" value="false"/>
<setting name="path" value="C:\temp\"/>
<setting name="stream.write.limit" value="1024"/>
<setting name="trace.traffic" value="false"/>
</group>

If the above parameters must be injected, the following names should be used:

  • orchestra_settings_AuditService_monitor_base64
  • orchestra_settings_AuditService_monitor_enabled
  • orchestra_settings_AuditService_monitor_path
  • orchestra_settings_AuditService_monitor_reason
  • orchestra_settings_AuditService_path
  • orchestra_settings_AuditService_stream_write_limit
  • orchestra_settings_AuditService_trace_traffic

Orchestra scenarios contain a wide range of settings that need to be injected. Currently, the following elements support injection:

  • Landscape entries
  • Security settings
  • Timers
  • Lookup tables
  • Channels (Start/Stop state)

To export the relevant properties from the Orchestra Designer, select the menu entry File | Export configuration. Using this command, you can export a file that contains all settings that can be overwritten.

Landscape Entries​

The basic pattern for all landscape values is:

<scenarioName>_landscape_<NameOfEnvironmentEntry>_<NameOfProperty>

The following example shows how the exported parameters look for an environment entry of type sap-server:

# Landscape settings of sap_server (SAP server connection)
# Gateway host
Injection_landscape_sap_server_GW_Host = x
# Gateway service
Injection_landscape_sap_server_GW_Service = x
# Program ID (registered server)
Injection_landscape_sap_server_Prog_ID = x
# Number of parallel requests
Injection_landscape_sap_server_Connections = 1

Security Settings​

The basic pattern for all security-related values is:

<scenarioName>_security_<NameOfCredential>_<AuthenticationType>_<NameOfProperty>

The following example shows how the parameters look for a credential that uses all different types of authentication:

# Security settings of credential_test
# Authentication type: pkcs12
# The password of the key store in plaintext or encrypted
Injection_security_credential_test_pkcs_store_password = oknrmvERnQQMk/FiU/mqVBKTHZjflgFbgZ3PE4zZUKAT0DQ=
# The password of the key in plaintext or encrypted
Injection_security_credential_test_pkcs_key_password = jpsmP2tjpRy7xBgi6zUqurqTLZkmKjv9EgKJ47P58vWhnoc=
# PKCS12-Keypair in Base64-encoded form or file-URI
Injection_security_credential_test_pkcs_keyfile = <Base64-encoded form or file-URI>

# Authentication type: ssh
# The name of the ssh user
Injection_security_credential_test_ssh_username = testSshUserXXX
# The password of the ssh-keystore in plaintext or encrypted
Injection_security_credential_test_ssh_password = jushndppediM+cVLGkprH7+SgYzmKmdOyK27qN+Uw66JToM=
# SSH-Key in Base64-encoded form or file-URI
Injection_security_credential_test_ssh_keyfile = U

# Authentication type: certificate
# X509Certificate in Base64-encoded form or file-URI
Injection_security_credential_test_cert_keyfile =

# Authentication type: Password
# The name of the user
Injection_security_credential_test_pwd_username = xxxx
# The password in plaintext or encrypted
Injection_security_credential_test_pwd_password = grvkKbUa871y84LPc+4gmF9dAJalNlyWju4V70WirKq0Pyc=

Timers​

The basic pattern for all timers is:

<scenarioName>_timer_<NameOfTimerOwner>_<NameOfTimer>_<NameOfProperty>

The following example shows how the exported parameters look for a periodic timer of a start event of a process model:

# Timer settings of Injection

# Description: Periodical timer
# Trigger type, Choices: [daily|monthly]
Injection_timer_processModel_id101_trigger = daily
# Trigger daily, Comma separated of days: Mon,Tue,Wed,Thu,Fri,Sat,Sun
Injection_timer_processModel_id101_daily = Mon,Tue,Wed,Thu,Fri,Sat,Sun
# Trigger monthly, Day of month
Injection_timer_processModel_id101_monthly = 1
# Timer type, Choices: [absolute|periodically]
Injection_timer_processModel_id101_timerType = periodically
# Start time
Injection_timer_processModel_id101_startTime = 00:00:00
# End time
Injection_timer_processModel_id101_endTime = 23:59:59
# Repeat count
Injection_timer_processModel_id101_repeatCount = -1
# Repeat interval
Injection_timer_processModel_id101_repeatInterval = 10,SECOND
# Activation, Choices: [DEFAULT|EXACT]
Injection_timer_processModel_id101_activation = DEFAULT

Lookup Tables​

The basic pattern for all lookup tables is:

<scenarioName>_lookuptable_<NameOfLookupTable>_<NameOfProperty>

The following example illustrates how the exported parameters look for a lookup table:

# Lookup table lt (INTERNAL)
# Default mode, Choices: [ERROR|USEDEFAULT]
Injection_lookupTable_lt_defaultMode = ERROR
# Default value
Injection_lookupTable_lt_default = null
# Re-deployment strategy, Choices: [OVERWRITE|PRESERVE]
Injection_lookupTable_lt_redeploymentStrategy = OVERWRITE
# Internal lookup mapping
Injection_lookupTable_lt_map_k1 = v1
Injection_lookupTable_lt_map_k2 = v2
Injection_lookupTable_lt_map_k3 = v3
Injection_lookupTable_lt_map_k4 = v4

Alternatively, the internal lookup table mapping can be defined by Base64-encoded or file-URI:

# Internal lookup mapping
Injection_lookupTable_lt_content = <Base64/File-URI>

Channels​

The basic pattern for all channels is:

<scenarioName>_channel_<NameOfChannel>_state

The following example shows how the exported parameters look for a channel:

# Adapter state, Choices: [RUNNING|STOPPED]
Injection_channel_ch_state = RUNNING

Important: If you use a variable that allows <Base64-encoded form or file-URI>, Orchestra will assume by default that the value is provided as Base64. If Orchestra needs to read a file, the parameter must start with the prefix file:/, expecting a correct file-URI. In case that both values do not match, the plaintext will be used.

Orchestra permits the creation of user-defined components that are hosted and executed within an Orchestra server. The configuration of an extended component can also be injected. The names of the properties are constructed dynamically from the configuration settings of the deployed components. The basic pattern is:

component_<applicationPackageName>_<componentName>_(concatenated-path-of-identifiers)

If the component references a parameter value, the value is taken from the environment rather than the persisted value.

Assuming the following XML configuration resides in the application package "app" and is named "instance":

<?xml version="1.0" encoding="UTF-8"?>
<configuration KEY1="VALUE1" KEY2="VALUE2" KEY3="VALUE3">
<group identifier="ID1" type="group1">
<parameter identifier="P9" type="group1.param1">
<value>group1.param1</value>
</parameter>
<parameter identifier="P10" type="group1.param2">
<value>group1.param2</value>
</parameter>
</group>
<group identifier="ID2" type="group2">
<group identifier="ID2a" type="group2a">
<parameter identifier="P15" type="group2.param1">
<value>group2.param1</value>
</parameter>
</group>
</group>
</configuration>

If the above parameters need to be injected, the following names must be used:

  • component_app_instance_att_KEY1
  • component_app_instance_att_KEY2
  • component_app_instance_att_KEY3
  • component_app_instance_ID1_P9
  • component_app_instance_ID1_P10
  • component_app_instance_ID2_ID2a_P15